
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="zh_Hans">
  <head>
    <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Django 1.2 版本发行说明 &#8212; Django 3.2.11.dev 文档</title>
    <link rel="stylesheet" href="../_static/default.css" type="text/css" />
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
    <script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <script type="text/javascript" src="../_static/language_data.js"></script>
    <link rel="index" title="索引" href="../genindex.html" />
    <link rel="search" title="搜索" href="../search.html" />
    <link rel="next" title="Django 1.1.4 版本发行说明" href="1.1.4.html" />
    <link rel="prev" title="Django 1.2.1 版本发行说明" href="1.2.1.html" />



 
<script src="../templatebuiltins.js"></script>
<script>
(function($) {
    if (!django_template_builtins) {
       // templatebuiltins.js missing, do nothing.
       return;
    }
    $(document).ready(function() {
        // Hyperlink Django template tags and filters
        var base = "../ref/templates/builtins.html";
        if (base == "#") {
            // Special case for builtins.html itself
            base = "";
        }
        // Tags are keywords, class '.k'
        $("div.highlight\\-html\\+django span.k").each(function(i, elem) {
             var tagname = $(elem).text();
             if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
                 var fragment = tagname.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
             }
        });
        // Filters are functions, class '.nf'
        $("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
             var filtername = $(elem).text();
             if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
                 var fragment = filtername.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
             }
        });
    });
})(jQuery);</script>

  </head><body>

    <div class="document">
  <div id="custom-doc" class="yui-t6">
    <div id="hd">
      <h1><a href="../index.html">Django 3.2.11.dev 文档</a></h1>
      <div id="global-nav">
        <a title="Home page" href="../index.html">Home</a>  |
        <a title="Table of contents" href="../contents.html">Table of contents</a>  |
        <a title="Global index" href="../genindex.html">Index</a>  |
        <a title="Module index" href="../py-modindex.html">Modules</a>
      </div>
      <div class="nav">
    &laquo; <a href="1.2.1.html" title="Django 1.2.1 版本发行说明">previous</a>
     |
    <a href="index.html" title="发行说明" accesskey="U">up</a>
   |
    <a href="1.1.4.html" title="Django 1.1.4 版本发行说明">next</a> &raquo;</div>
    </div>

    <div id="bd">
      <div id="yui-main">
        <div class="yui-b">
          <div class="yui-g" id="releases-1.2">
            
  <div class="section" id="s-django-1-2-release-notes">
<span id="django-1-2-release-notes"></span><h1>Django 1.2 版本发行说明<a class="headerlink" href="#django-1-2-release-notes" title="永久链接至标题">¶</a></h1>
<p><em>2017 年 5 月 17 日</em></p>
<p>欢迎来到 Django 1.2 版本！</p>
<p>Nearly a year in the making, Django 1.2 packs an impressive list of <a class="reference internal" href="#whats-new-1-2"><span class="std std-ref">new
features</span></a> and lots of bug fixes. These release notes cover
the new features, as well as important changes you'll want to be aware of when
upgrading from Django 1.1 or older versions.</p>
<div class="section" id="s-overview">
<span id="overview"></span><h2>概况<a class="headerlink" href="#overview" title="永久链接至标题">¶</a></h2>
<p>Django 1.2 introduces several large, important new features, including:</p>
<ul class="simple">
<li>Support for <a class="reference internal" href="#support-for-multiple-databases"><span class="std std-ref">multiple database connections</span></a> in a single Django instance.</li>
<li><a class="reference internal" href="#model-validation">Model validation</a> inspired by Django's form validation.</li>
<li>Vastly <a class="reference internal" href="#improved-csrf-protection"><span class="std std-ref">improved protection against Cross-Site Request Forgery</span></a> (CSRF).</li>
<li>A new <a class="reference internal" href="#messages-framework"><span class="std std-ref">user &quot;messages&quot; framework</span></a> with support for
cookie- and session-based message for both anonymous and authenticated users.</li>
<li>Hooks for <a class="reference internal" href="#object-level-permissions">object-level permissions</a>, <a class="reference internal" href="#permissions-for-anonymous-users">permissions for anonymous users</a>,
and <a class="reference internal" href="#relaxed-requirements-for-usernames"><span class="std std-ref">more flexible username requirements</span></a>.</li>
<li>Customization of email sending via <a class="reference internal" href="#email-backends">email backends</a>.</li>
<li>New <a class="reference internal" href="#new-in-1-2-smart-if"><span class="std std-ref">&quot;smart&quot; if template tag</span></a> which supports
comparison operators.</li>
</ul>
<p>These are just the highlights; full details and a complete list of features
<a class="reference internal" href="#whats-new-1-2"><span class="std std-ref">may be found below</span></a>.</p>
<div class="admonition seealso">
<p class="first admonition-title">参见</p>
<p class="last"><a class="reference external" href="https://github.com/djangoadvent/djangoadvent-articles">Django Advent</a> covered the release of Django 1.2 with a series of
articles and tutorials that cover some of the new features in depth.</p>
</div>
<p>Wherever possible these features have been introduced in a backwards-compatible
manner per <a class="reference internal" href="../misc/api-stability.html"><span class="doc">our API stability policy</span></a> policy.</p>
<p>However, a handful of features <em>have</em> changed in ways that, for some users, will be
backwards-incompatible. The big changes are:</p>
<ul>
<li><p class="first">Support for Python 2.3 has been dropped. See the full notes
below.</p>
</li>
<li><p class="first">The new CSRF protection framework is not backwards-compatible with
the old system. Users of the old system will not be affected until
the old system is removed in Django 1.4.</p>
<p>However, upgrading to the new CSRF protection framework requires a few
important backwards-incompatible changes, detailed in <a class="reference internal" href="#csrf-protection">CSRF Protection</a>,
below.</p>
</li>
<li><p class="first">Authors of custom <a class="reference internal" href="../ref/models/fields.html#django.db.models.Field" title="django.db.models.Field"><code class="xref py py-class docutils literal notranslate"><span class="pre">Field</span></code></a> subclasses should be
aware that a number of methods have had a change in prototype, detailed
under <a class="reference internal" href="#get-db-prep-methods-on-field">get_db_prep_*() methods on Field</a>, below.</p>
</li>
<li><p class="first">The internals of template tags have changed somewhat; authors of custom
template tags that need to store state (e.g. custom control flow tags)
should ensure that their code follows the new rules for <a class="reference internal" href="#stateful-template-tags">stateful template
tags</a></p>
</li>
<li><p class="first">The <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.user_passes_test" title="django.contrib.auth.decorators.user_passes_test"><code class="xref py py-func docutils literal notranslate"><span class="pre">user_passes_test()</span></code></a>,
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.login_required" title="django.contrib.auth.decorators.login_required"><code class="xref py py-func docutils literal notranslate"><span class="pre">login_required()</span></code></a>, and
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.permission_required" title="django.contrib.auth.decorators.permission_required"><code class="xref py py-func docutils literal notranslate"><span class="pre">permission_required()</span></code></a>, decorators
from <a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><code class="xref py py-mod docutils literal notranslate"><span class="pre">django.contrib.auth</span></code></a> only apply to functions and no longer
work on methods. There's a simple one-line fix <a class="reference internal" href="#user-passes-test-login-required-permission-required"><span class="std std-ref">detailed below</span></a>.</p>
</li>
</ul>
<p>Again, these are just the big features that will affect the most users. Users
upgrading from previous versions of Django are heavily encouraged to consult
the complete list of <a class="reference internal" href="#backwards-incompatible-changes-1-2"><span class="std std-ref">backwards-incompatible changes</span></a> and the list of <a class="reference internal" href="#deprecated-features-1-2"><span class="std std-ref">deprecated
features</span></a>.</p>
</div>
<div class="section" id="s-python-compatibility">
<span id="python-compatibility"></span><h2>Python 兼容性<a class="headerlink" href="#python-compatibility" title="永久链接至标题">¶</a></h2>
<p>While not a new feature, it's important to note that Django 1.2
introduces the first shift in our Python compatibility policy since
Django's initial public debut. Previous Django releases were tested
and supported on 2.x Python versions from 2.3 up; Django 1.2, however,
drops official support for Python 2.3. As such, the minimum Python
version required for Django is now 2.4, and Django is tested and
supported on Python 2.4, 2.5 and 2.6, and will be supported on the
as-yet-unreleased Python 2.7.</p>
<p>This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.4 or newer as
their default version. If you're still using Python 2.3, however,
you'll need to stick to Django 1.1 until you can upgrade; per
<a class="reference internal" href="../internals/release-process.html"><span class="doc">our support policy</span></a>, Django 1.1 will
continue to receive security support until the release of Django 1.3.</p>
<p>A roadmap for Django's overall 2.x Python support, and eventual
transition to Python 3.x, is currently being developed, and will be
announced prior to the release of Django 1.3.</p>
</div>
<div class="section" id="s-what-s-new-in-django-1-2">
<span id="s-whats-new-1-2"></span><span id="what-s-new-in-django-1-2"></span><span id="whats-new-1-2"></span><h2>Django 1.2 新特性<a class="headerlink" href="#what-s-new-in-django-1-2" title="永久链接至标题">¶</a></h2>
<div class="section" id="s-support-for-multiple-databases">
<span id="s-id1"></span><span id="support-for-multiple-databases"></span><span id="id1"></span><h3>Support for multiple databases<a class="headerlink" href="#support-for-multiple-databases" title="永久链接至标题">¶</a></h3>
<p>Django 1.2 adds the ability to use <a class="reference internal" href="../topics/db/multi-db.html"><span class="doc">more than one database</span></a> in your Django project. Queries can be issued at a
specific database with the <code class="docutils literal notranslate"><span class="pre">using()</span></code> method on <code class="docutils literal notranslate"><span class="pre">QuerySet</span></code> objects.
Individual objects can be saved to a specific database by providing a <code class="docutils literal notranslate"><span class="pre">using</span></code>
argument when you call <code class="docutils literal notranslate"><span class="pre">save()</span></code>.</p>
</div>
<div class="section" id="s-model-validation">
<span id="model-validation"></span><h3>Model validation<a class="headerlink" href="#model-validation" title="永久链接至标题">¶</a></h3>
<p>Model instances now have support for <a class="reference internal" href="../ref/models/instances.html#validating-objects"><span class="std std-ref">validating their own data</span></a>, and both model and form fields now accept configurable
lists of <a class="reference internal" href="../ref/validators.html"><span class="doc">validators</span></a> specifying reusable, encapsulated
validation behavior. Note, however, that validation must still be performed
explicitly. Simply invoking a model instance's <code class="docutils literal notranslate"><span class="pre">save()</span></code> method will not
perform any validation of the instance's data.</p>
</div>
<div class="section" id="s-improved-csrf-protection">
<span id="s-id2"></span><span id="improved-csrf-protection"></span><span id="id2"></span><h3>Improved CSRF protection<a class="headerlink" href="#improved-csrf-protection" title="永久链接至标题">¶</a></h3>
<p>Django now has much improved protection against <a class="reference internal" href="../ref/csrf.html"><span class="doc">Cross-Site Request Forgery
(CSRF) attacks</span></a>. This type of attack occurs when a malicious
website contains a link, a form button or some JavaScript that is intended to
perform some action on your website, using the credentials of a logged-in user
who visits the malicious site in their browser. A related type of attack, &quot;login
CSRF,&quot; where an attacking site tricks a user's browser into logging into a site
with someone else's credentials, is also covered.</p>
</div>
<div class="section" id="s-messages-framework">
<span id="s-id3"></span><span id="messages-framework"></span><span id="id3"></span><h3>Messages framework<a class="headerlink" href="#messages-framework" title="永久链接至标题">¶</a></h3>
<p>Django now includes a robust and configurable <a class="reference internal" href="../ref/contrib/messages.html"><span class="doc">messages framework</span></a> with built-in support for cookie- and session-based
messaging, for both anonymous and authenticated clients. The messages framework
replaces the deprecated user message API and allows you to temporarily store
messages in one request and retrieve them for display in a subsequent request
(usually the next one).</p>
</div>
<div class="section" id="s-object-level-permissions">
<span id="object-level-permissions"></span><h3>对象级权限<a class="headerlink" href="#object-level-permissions" title="永久链接至标题">¶</a></h3>
<p>A foundation for specifying permissions at the per-object level has been added.
Although there is no implementation of this in core, a custom authentication
backend can provide this implementation and it will be used by
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><code class="xref py py-class docutils literal notranslate"><span class="pre">django.contrib.auth.models.User</span></code></a>. See the <a class="reference internal" href="../topics/auth/index.html"><span class="doc">authentication docs</span></a> for more information.</p>
</div>
<div class="section" id="s-permissions-for-anonymous-users">
<span id="permissions-for-anonymous-users"></span><h3>Permissions for anonymous users<a class="headerlink" href="#permissions-for-anonymous-users" title="永久链接至标题">¶</a></h3>
<p>If you provide a custom auth backend with <code class="docutils literal notranslate"><span class="pre">supports_anonymous_user</span></code> set to
<code class="docutils literal notranslate"><span class="pre">True</span></code>, AnonymousUser will check the backend for permissions, just like
User already did.  This is useful for centralizing permission handling - apps
can always delegate the question of whether something is allowed or not to
the authorization/authentication backend. See the <a class="reference internal" href="../topics/auth/index.html"><span class="doc">authentication
docs</span></a> for more details.</p>
</div>
<div class="section" id="s-relaxed-requirements-for-usernames">
<span id="s-id4"></span><span id="relaxed-requirements-for-usernames"></span><span id="id4"></span><h3>Relaxed requirements for usernames<a class="headerlink" href="#relaxed-requirements-for-usernames" title="永久链接至标题">¶</a></h3>
<p>The built-in <a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User" title="django.contrib.auth.models.User"><code class="xref py py-class docutils literal notranslate"><span class="pre">User</span></code></a> model's
<a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.username" title="django.contrib.auth.models.User.username"><code class="xref py py-attr docutils literal notranslate"><span class="pre">username</span></code></a> field now allows a wider range
of characters, including <code class="docutils literal notranslate"><span class="pre">&#64;</span></code>, <code class="docutils literal notranslate"><span class="pre">+</span></code>, <code class="docutils literal notranslate"><span class="pre">.</span></code> and <code class="docutils literal notranslate"><span class="pre">-</span></code> characters.</p>
</div>
<div class="section" id="s-email-backends">
<span id="email-backends"></span><h3>邮件后端<a class="headerlink" href="#email-backends" title="永久链接至标题">¶</a></h3>
<p>You can now <a class="reference internal" href="../topics/email.html#topic-email-backends"><span class="std std-ref">configure the way that Django sends email</span></a>. Instead of using SMTP to send all email, you
can now choose a configurable email backend to send messages. If your
hosting provider uses a sandbox or some other non-SMTP technique for
sending mail, you can now construct an email backend that will allow
Django's standard <a class="reference internal" href="../topics/email.html"><span class="doc">mail sending methods</span></a> to use
those facilities.</p>
<p>This also makes it easier to debug mail sending. Django ships with
backend implementations that allow you to send email to a
<a class="reference internal" href="../topics/email.html#topic-email-file-backend"><span class="std std-ref">file</span></a>, to the
<a class="reference internal" href="../topics/email.html#topic-email-console-backend"><span class="std std-ref">console</span></a>, or to
<a class="reference internal" href="../topics/email.html#topic-email-memory-backend"><span class="std std-ref">memory</span></a>. You can even configure all
email to be <a class="reference internal" href="../topics/email.html#topic-email-dummy-backend"><span class="std std-ref">thrown away</span></a>.</p>
</div>
<div class="section" id="s-smart-if-tag">
<span id="s-new-in-1-2-smart-if"></span><span id="smart-if-tag"></span><span id="new-in-1-2-smart-if"></span><h3>&quot;Smart&quot; <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">if</span></code></a> tag<a class="headerlink" href="#smart-if-tag" title="永久链接至标题">¶</a></h3>
<p>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">if</span></code></a> tag has been upgraded to be much more powerful. First, we've
added support for comparison operators. No longer will you have to type:</p>
<div class="highlight-html+django notranslate"><div class="highlight"><pre><span></span><span class="cp">{%</span> <span class="k">ifnotequal</span> <span class="nv">a</span> <span class="nv">b</span> <span class="cp">%}</span>
 ...
<span class="cp">{%</span> <span class="k">endifnotequal</span> <span class="cp">%}</span>
</pre></div>
</div>
<p>You can now do this:</p>
<div class="highlight-html+django notranslate"><div class="highlight"><pre><span></span><span class="cp">{%</span> <span class="k">if</span> <span class="nv">a</span> <span class="o">!=</span> <span class="nv">b</span> <span class="cp">%}</span>
 ...
<span class="cp">{%</span> <span class="k">endif</span> <span class="cp">%}</span>
</pre></div>
</div>
<p>There's really no reason to use <code class="docutils literal notranslate"><span class="pre">{%</span> <span class="pre">ifequal</span> <span class="pre">%}</span></code> or <code class="docutils literal notranslate"><span class="pre">{%</span> <span class="pre">ifnotequal</span> <span class="pre">%}</span></code>
anymore, unless you're the nostalgic type.</p>
<p>The operators supported are <code class="docutils literal notranslate"><span class="pre">==</span></code>, <code class="docutils literal notranslate"><span class="pre">!=</span></code>, <code class="docutils literal notranslate"><span class="pre">&lt;</span></code>, <code class="docutils literal notranslate"><span class="pre">&gt;</span></code>, <code class="docutils literal notranslate"><span class="pre">&lt;=</span></code>, <code class="docutils literal notranslate"><span class="pre">&gt;=</span></code>,
<code class="docutils literal notranslate"><span class="pre">in</span></code> and <code class="docutils literal notranslate"><span class="pre">not</span> <span class="pre">in</span></code>, all of which work like the Python operators, in addition
to <code class="docutils literal notranslate"><span class="pre">and</span></code>, <code class="docutils literal notranslate"><span class="pre">or</span></code> and <code class="docutils literal notranslate"><span class="pre">not</span></code>, which were already supported.</p>
<p>Also, filters may now be used in the <code class="docutils literal notranslate"><span class="pre">if</span></code> expression. For example:</p>
<div class="highlight-html+django notranslate"><div class="highlight"><pre><span></span><span class="p">&lt;</span><span class="nt">div</span>
  <span class="cp">{%</span> <span class="k">if</span> <span class="nv">user.email</span><span class="o">|</span><span class="nf">lower</span> <span class="o">==</span> <span class="nv">message.recipient</span><span class="o">|</span><span class="nf">lower</span> <span class="cp">%}</span>
    <span class="na">class</span><span class="o">=</span><span class="s">&quot;highlight&quot;</span>
  <span class="cp">{%</span> <span class="k">endif</span> <span class="cp">%}</span>
<span class="p">&gt;</span><span class="cp">{{</span> <span class="nv">message</span> <span class="cp">}}</span><span class="p">&lt;/</span><span class="nt">div</span><span class="p">&gt;</span>
</pre></div>
</div>
</div>
<div class="section" id="s-template-caching">
<span id="template-caching"></span><h3>Template caching<a class="headerlink" href="#template-caching" title="永久链接至标题">¶</a></h3>
<p>In previous versions of Django, every time you rendered a template, it
would be reloaded from disk. In Django 1.2, you can use a <a class="reference internal" href="../ref/templates/api.html#template-loaders"><span class="std std-ref">cached
template loader</span></a> to load templates once, then
cache the result for every subsequent render. This can lead to a
significant performance improvement if your templates are broken into
lots of smaller subtemplates (using the <code class="docutils literal notranslate"><span class="pre">{%</span> <span class="pre">extends</span> <span class="pre">%}</span></code> or <code class="docutils literal notranslate"><span class="pre">{%</span>
<span class="pre">include</span> <span class="pre">%}</span></code> tags).</p>
<p>As a side effect, it is now much easier to support non-Django template
languages.</p>
</div>
<div class="section" id="s-class-based-template-loaders">
<span id="class-based-template-loaders"></span><h3>Class-based template loaders<a class="headerlink" href="#class-based-template-loaders" title="永久链接至标题">¶</a></h3>
<p>As part of the changes made to introduce <a class="reference internal" href="#template-caching">Template caching</a>  and following
a general trend in Django, the template loaders API has been modified
to use template loading mechanisms that are encapsulated in Python classes as
opposed to functions, the only method available until Django 1.1.</p>
<p>All the template loaders <a class="reference internal" href="../ref/templates/api.html#template-loaders"><span class="std std-ref">shipped with Django</span></a> have
been ported to the new API but they still implement the function-based API and
the template core machinery still accepts function-based loaders (builtin or
third party) so there is no immediate need to modify your <code class="docutils literal notranslate"><span class="pre">TEMPLATE_LOADERS</span></code>
setting in existing projects, things will keep working if you leave it
untouched up to and including the Django 1.3 release.</p>
<p>If you have developed your own custom template loaders we suggest to consider
porting them to a class-based implementation because the code for backwards
compatibility with function-based loaders starts its deprecation process in
Django 1.2 and will be removed in Django 1.4.  There is a description of the
API these loader classes must implement in the template API reference and you
can also examine the source code of the loaders shipped with Django.</p>
</div>
<div class="section" id="s-natural-keys-in-fixtures">
<span id="natural-keys-in-fixtures"></span><h3>Natural keys in fixtures<a class="headerlink" href="#natural-keys-in-fixtures" title="永久链接至标题">¶</a></h3>
<p>Fixtures can now refer to remote objects using
<a class="reference internal" href="../topics/serialization.html#topics-serialization-natural-keys"><span class="std std-ref">自然键</span></a>. This lookup scheme is an
alternative to the normal primary-key based object references in a
fixture, improving readability and resolving problems referring to
objects whose primary key value may not be predictable or known.</p>
</div>
<div class="section" id="s-fast-failure-for-tests">
<span id="fast-failure-for-tests"></span><h3>Fast failure for tests<a class="headerlink" href="#fast-failure-for-tests" title="永久链接至标题">¶</a></h3>
<p>Both the <a class="reference internal" href="../ref/django-admin.html#django-admin-test"><code class="xref std std-djadmin docutils literal notranslate"><span class="pre">test</span></code></a> subcommand of <code class="docutils literal notranslate"><span class="pre">django-admin.py</span></code> and the
<code class="docutils literal notranslate"><span class="pre">runtests.py</span></code> script used to run Django's own test suite now support a
<code class="docutils literal notranslate"><span class="pre">--failfast</span></code> option. When specified, this option causes the test runner to
exit after encountering a failure instead of continuing with the test run. In
addition, the handling of <code class="docutils literal notranslate"><span class="pre">Ctrl-C</span></code> during a test run has been improved to
trigger a graceful exit from the test run that reports details of the tests that
were run before the interruption.</p>
</div>
<div class="section" id="s-bigintegerfield">
<span id="bigintegerfield"></span><h3><code class="docutils literal notranslate"><span class="pre">BigIntegerField</span></code><a class="headerlink" href="#bigintegerfield" title="永久链接至标题">¶</a></h3>
<p>Models can now use a 64-bit <a class="reference internal" href="../ref/models/fields.html#django.db.models.BigIntegerField" title="django.db.models.BigIntegerField"><code class="xref py py-class docutils literal notranslate"><span class="pre">BigIntegerField</span></code></a> type.</p>
</div>
<div class="section" id="s-improved-localization">
<span id="improved-localization"></span><h3>Improved localization<a class="headerlink" href="#improved-localization" title="永久链接至标题">¶</a></h3>
<p>Django's <a class="reference internal" href="../topics/i18n/index.html"><span class="doc">internationalization framework</span></a> has been expanded
with locale-aware formatting and form processing. That means, if enabled, dates
and numbers on templates will be displayed using the format specified for the
current locale. Django will also use localized formats when parsing data in
forms. See <a class="reference internal" href="../topics/i18n/formatting.html"><span class="doc">本地格式化</span></a> for more details.</p>
</div>
<div class="section" id="s-readonly-fields-in-modeladmin">
<span id="readonly-fields-in-modeladmin"></span><h3><code class="docutils literal notranslate"><span class="pre">readonly_fields</span></code> in <code class="docutils literal notranslate"><span class="pre">ModelAdmin</span></code><a class="headerlink" href="#readonly-fields-in-modeladmin" title="永久链接至标题">¶</a></h3>
<p><a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.readonly_fields" title="django.contrib.admin.ModelAdmin.readonly_fields"><code class="xref py py-attr docutils literal notranslate"><span class="pre">django.contrib.admin.ModelAdmin.readonly_fields</span></code></a> has been added to
enable non-editable fields in add/change pages for models and inlines. Field
and calculated values can be displayed alongside editable fields.</p>
</div>
<div class="section" id="s-customizable-syntax-highlighting">
<span id="customizable-syntax-highlighting"></span><h3>Customizable syntax highlighting<a class="headerlink" href="#customizable-syntax-highlighting" title="永久链接至标题">¶</a></h3>
<p>You can now use a <span class="target" id="index-0"></span><a class="reference internal" href="../ref/django-admin.html#envvar-DJANGO_COLORS"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">DJANGO_COLORS</span></code></a> environment variable to modify or
disable the colors used by <code class="docutils literal notranslate"><span class="pre">django-admin.py</span></code> to provide <a class="reference internal" href="../ref/django-admin.html#syntax-coloring"><span class="std std-ref">syntax
highlighting</span></a>.</p>
</div>
<div class="section" id="s-syndication-feeds-as-views">
<span id="syndication-feeds-as-views"></span><h3>Syndication feeds as views<a class="headerlink" href="#syndication-feeds-as-views" title="永久链接至标题">¶</a></h3>
<p><a class="reference internal" href="../ref/contrib/syndication.html"><span class="doc">Syndication feeds</span></a> can now be used directly as
views in your <a class="reference internal" href="../topics/http/urls.html"><span class="doc">URLconf</span></a>. This means that you can
maintain complete control over the URL structure of your feeds. Like any other
view, feeds views are passed a <code class="docutils literal notranslate"><span class="pre">request</span></code> object, so you can do anything you
would normally do with a view, like user based access control, or making a feed
a named URL.</p>
</div>
<div class="section" id="s-geodjango">
<span id="geodjango"></span><h3>GeoDjango<a class="headerlink" href="#geodjango" title="永久链接至标题">¶</a></h3>
<p>The most significant new feature for <a class="reference internal" href="../ref/contrib/gis/index.html"><span class="doc">GeoDjango</span></a>
in 1.2 is support for multiple spatial databases.  As a result,
the following <a class="reference internal" href="../ref/contrib/gis/db-api.html#spatial-backends"><span class="std std-ref">spatial database backends</span></a>
are now included:</p>
<ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backends.postgis</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backends.mysql</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backends.oracle</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backends.spatialite</span></code></li>
</ul>
<p>GeoDjango now supports the rich capabilities added in the PostGIS 1.5 release.
New features include support for the <a class="reference internal" href="../ref/contrib/gis/model-api.html#geography-type"><span class="std std-ref">geography type</span></a>
and enabling of <a class="reference internal" href="../ref/contrib/gis/db-api.html#distance-queries"><span class="std std-ref">distance queries</span></a>
with non-point geometries on geographic coordinate systems.</p>
<p>Support for 3D geometry fields was added, and may be enabled
by setting the <a class="reference internal" href="../ref/contrib/gis/model-api.html#django.contrib.gis.db.models.GeometryField.dim" title="django.contrib.gis.db.models.GeometryField.dim"><code class="xref py py-attr docutils literal notranslate"><span class="pre">dim</span></code></a>
keyword to 3 in your <a class="reference internal" href="../ref/contrib/gis/model-api.html#django.contrib.gis.db.models.GeometryField" title="django.contrib.gis.db.models.GeometryField"><code class="xref py py-class docutils literal notranslate"><span class="pre">GeometryField</span></code></a>.
The <a class="reference internal" href="../ref/contrib/gis/geoquerysets.html#django.contrib.gis.db.models.Extent3D" title="django.contrib.gis.db.models.Extent3D"><code class="xref py py-class docutils literal notranslate"><span class="pre">Extent3D</span></code></a> aggregate
and <code class="docutils literal notranslate"><span class="pre">extent3d()</span></code> <code class="docutils literal notranslate"><span class="pre">GeoQuerySet</span></code> method were added as a part of this feature.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">force_rhr()</span></code>, <code class="docutils literal notranslate"><span class="pre">reverse_geom()</span></code>, and <code class="docutils literal notranslate"><span class="pre">geohash()</span></code> <code class="docutils literal notranslate"><span class="pre">GeoQuerySet</span></code>
methods are new.</p>
<p>The GEOS interface was updated to use thread-safe C library functions when
available on the platform.</p>
<p>The GDAL interface now allows the user to set a
<a class="reference internal" href="../ref/contrib/gis/gdal.html#django.contrib.gis.gdal.Layer.spatial_filter" title="django.contrib.gis.gdal.Layer.spatial_filter"><code class="xref py py-attr docutils literal notranslate"><span class="pre">spatial_filter</span></code></a> on the features returned
when iterating over a <a class="reference internal" href="../ref/contrib/gis/gdal.html#django.contrib.gis.gdal.Layer" title="django.contrib.gis.gdal.Layer"><code class="xref py py-class docutils literal notranslate"><span class="pre">Layer</span></code></a>.</p>
<p>Finally, <a class="reference internal" href="../ref/contrib/gis/index.html"><span class="doc">GeoDjango's documentation</span></a> is now
included with Django's and is no longer hosted separately at <code class="docutils literal notranslate"><span class="pre">geodjango.org</span></code>.</p>
</div>
<div class="section" id="s-javascript-assisted-handling-of-inline-related-objects-in-the-admin">
<span id="s-js-assisted-inlines"></span><span id="javascript-assisted-handling-of-inline-related-objects-in-the-admin"></span><span id="js-assisted-inlines"></span><h3>JavaScript-assisted handling of inline related objects in the admin<a class="headerlink" href="#javascript-assisted-handling-of-inline-related-objects-in-the-admin" title="永久链接至标题">¶</a></h3>
<p>If a user has JavaScript enabled in their browser, the interface for
inline objects in the admin now allows inline objects to be
dynamically added and removed. Users without JavaScript-enabled
browsers will see no change in the behavior of inline objects.</p>
</div>
<div class="section" id="s-new-now-template-tag-format-specifier-characters-c-and-u">
<span id="new-now-template-tag-format-specifier-characters-c-and-u"></span><h3>New <code class="docutils literal notranslate"><span class="pre">now</span></code> template tag format specifier characters: <code class="docutils literal notranslate"><span class="pre">c</span></code> and <code class="docutils literal notranslate"><span class="pre">u</span></code><a class="headerlink" href="#new-now-template-tag-format-specifier-characters-c-and-u" title="永久链接至标题">¶</a></h3>
<p>The argument to the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-now"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">now</span></code></a> has gained two new format characters:
<code class="docutils literal notranslate"><span class="pre">c</span></code> to specify that a datetime value should be formatted in ISO 8601
format, and <code class="docutils literal notranslate"><span class="pre">u</span></code> that allows output of the microseconds part of a
datetime or time value.</p>
<p>These are also available in others parts like the <a class="reference internal" href="../ref/templates/builtins.html#std:templatefilter-date"><code class="xref std std-tfilter docutils literal notranslate"><span class="pre">date</span></code></a> and
<a class="reference internal" href="../ref/templates/builtins.html#std:templatefilter-time"><code class="xref std std-tfilter docutils literal notranslate"><span class="pre">time</span></code></a> template filters, the <code class="docutils literal notranslate"><span class="pre">humanize</span></code> template tag library
and the new <a class="reference internal" href="#improved-localization">format localization</a> framework.</p>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-2">
<span id="s-backwards-incompatible-changes-1-2"></span><span id="backwards-incompatible-changes-in-1-2"></span><span id="backwards-incompatible-changes-1-2"></span><h2>Backwards-incompatible changes in 1.2<a class="headerlink" href="#backwards-incompatible-changes-in-1-2" title="永久链接至标题">¶</a></h2>
<p>Wherever possible the new features above have been introduced in a
backwards-compatible manner per <a class="reference internal" href="../misc/api-stability.html"><span class="doc">our API stability policy</span></a> policy. This means that practically all existing
code which worked with Django 1.1 will continue to work with Django
1.2; such code will, however, begin issuing warnings (see below for
details).</p>
<p>However, a handful of features <em>have</em> changed in ways that, for some
users, will be immediately backwards-incompatible. Those changes are
detailed below.</p>
<div class="section" id="s-csrf-protection">
<span id="csrf-protection"></span><h3>CSRF Protection<a class="headerlink" href="#csrf-protection" title="永久链接至标题">¶</a></h3>
<p>We've made large changes to the way CSRF protection works, detailed in
<a class="reference internal" href="../ref/csrf.html"><span class="doc">the CSRF documentation</span></a>. Here are the major changes you
should be aware of:</p>
<ul>
<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CsrfResponseMiddleware</span></code> and <code class="docutils literal notranslate"><span class="pre">CsrfMiddleware</span></code> have been deprecated and
will be removed completely in Django 1.4, in favor of a template tag that
should be inserted into forms.</p>
</li>
<li><p class="first">All contrib apps use a <code class="docutils literal notranslate"><span class="pre">csrf_protect</span></code> decorator to protect the view. This
requires the use of the <code class="docutils literal notranslate"><span class="pre">csrf_token</span></code> template tag in the template. If you
have used custom templates for contrib views, you MUST READ THE UPGRADE
INSTRUCTIONS to fix those templates.</p>
<div class="admonition-documentation-removed admonition">
<p class="first admonition-title">Documentation removed</p>
<p class="last">The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.</p>
</div>
</li>
<li><p class="first"><code class="docutils literal notranslate"><span class="pre">CsrfViewMiddleware</span></code> is included in <code class="docutils literal notranslate"><span class="pre">MIDDLEWARE_CLASSES</span></code> by
default. This turns on CSRF protection by default, so views that accept
POST requests need to be written to work with the middleware. Instructions
on how to do this are found in the CSRF docs.</p>
</li>
<li><p class="first">All of the CSRF has moved from contrib to core (with backwards
compatible imports in the old locations, which are deprecated and
will cease to be supported in Django 1.4).</p>
</li>
</ul>
</div>
<div class="section" id="s-get-db-prep-methods-on-field">
<span id="get-db-prep-methods-on-field"></span><h3><code class="docutils literal notranslate"><span class="pre">get_db_prep_*()</span></code> methods on <code class="docutils literal notranslate"><span class="pre">Field</span></code><a class="headerlink" href="#get-db-prep-methods-on-field" title="永久链接至标题">¶</a></h3>
<p>Prior to Django 1.2, a custom <code class="docutils literal notranslate"><span class="pre">Field</span></code> had the option of defining
several functions to support conversion of Python values into
database-compatible values. A custom field might look something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">CustomModelField</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Field</span><span class="p">):</span>
    <span class="c1"># ...</span>
    <span class="k">def</span> <span class="nf">db_type</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_save</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_value</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_lookup</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">lookup_type</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
        <span class="c1"># ...</span>
</pre></div>
</div>
<p>In 1.2, these three methods have undergone a change in prototype, and
two extra methods have been introduced:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">CustomModelField</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Field</span><span class="p">):</span>
    <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">db_type</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">connection</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_prep_value</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_prep_lookup</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">lookup_type</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_save</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">,</span> <span class="n">connection</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_value</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">,</span> <span class="n">connection</span><span class="p">,</span> <span class="n">prepared</span><span class="o">=</span><span class="kc">False</span><span class="p">):</span>
        <span class="c1"># ...</span>

    <span class="k">def</span> <span class="nf">get_db_prep_lookup</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">lookup_type</span><span class="p">,</span> <span class="n">value</span><span class="p">,</span> <span class="n">connection</span><span class="p">,</span> <span class="n">prepared</span><span class="o">=</span><span class="kc">False</span><span class="p">):</span>
        <span class="c1"># ...</span>
</pre></div>
</div>
<p>These changes are required to support multiple databases --
<code class="docutils literal notranslate"><span class="pre">db_type</span></code> and <code class="docutils literal notranslate"><span class="pre">get_db_prep_*</span></code> can no longer make any assumptions
regarding the database for which it is preparing. The <code class="docutils literal notranslate"><span class="pre">connection</span></code>
argument now provides the preparation methods with the specific
connection for which the value is being prepared.</p>
<p>The two new methods exist to differentiate general data-preparation
requirements from requirements that are database-specific. The
<code class="docutils literal notranslate"><span class="pre">prepared</span></code> argument is used to indicate to the database-preparation
methods whether generic value preparation has been performed. If
an unprepared (i.e., <code class="docutils literal notranslate"><span class="pre">prepared=False</span></code>) value is provided to the
<code class="docutils literal notranslate"><span class="pre">get_db_prep_*()</span></code> calls, they should invoke the corresponding
<code class="docutils literal notranslate"><span class="pre">get_prep_*()</span></code> calls to perform generic data preparation.</p>
<p>We've provided conversion functions that will transparently
convert functions adhering to the old prototype into functions
compatible with the new prototype. However, these conversion functions
will be removed in Django 1.4, so you should upgrade your <code class="docutils literal notranslate"><span class="pre">Field</span></code>
definitions to use the new prototype as soon as possible.</p>
<p>If your <code class="docutils literal notranslate"><span class="pre">get_db_prep_*()</span></code> methods made no use of the database
connection, you should be able to upgrade by renaming
<code class="docutils literal notranslate"><span class="pre">get_db_prep_value()</span></code> to <code class="docutils literal notranslate"><span class="pre">get_prep_value()</span></code> and
<code class="docutils literal notranslate"><span class="pre">get_db_prep_lookup()</span></code> to <code class="docutils literal notranslate"><span class="pre">get_prep_lookup()</span></code>. If you require
database specific conversions, then you will need to provide an
implementation <code class="docutils literal notranslate"><span class="pre">get_db_prep_*</span></code> that uses the <code class="docutils literal notranslate"><span class="pre">connection</span></code>
argument to resolve database-specific values.</p>
</div>
<div class="section" id="s-stateful-template-tags">
<span id="stateful-template-tags"></span><h3>Stateful template tags<a class="headerlink" href="#stateful-template-tags" title="永久链接至标题">¶</a></h3>
<p>Template tags that store rendering state on their <code class="docutils literal notranslate"><span class="pre">Node</span></code> subclass
have always been vulnerable to thread-safety and other issues; as of
Django 1.2, however, they may also cause problems when used with the
new <a class="reference internal" href="../ref/templates/api.html#template-loaders"><span class="std std-ref">cached template loader</span></a>.</p>
<p>All of the built-in Django template tags are safe to use with the cached
loader, but if you're using custom template tags that come from third
party packages, or from your own code, you should ensure that the
<code class="docutils literal notranslate"><span class="pre">Node</span></code> implementation for each tag is thread-safe. For more
information, see
<a class="reference internal" href="../howto/custom-template-tags.html#template-tag-thread-safety"><span class="std std-ref">template tag thread safety considerations</span></a>.</p>
<p>You may also need to update your templates if you were relying on the
implementation of Django's template tags <em>not</em> being thread safe. The
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">cycle</span></code></a> tag is the most likely to be affected in this way,
especially when used in conjunction with the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">include</span></code></a> tag.
Consider the following template fragment:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="k">for</span> <span class="nb">object</span> <span class="ow">in</span> <span class="n">object_list</span> <span class="o">%</span><span class="p">}</span>
    <span class="p">{</span><span class="o">%</span> <span class="n">include</span> <span class="s2">&quot;subtemplate.html&quot;</span> <span class="o">%</span><span class="p">}</span>
<span class="p">{</span><span class="o">%</span> <span class="n">endfor</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>with a <code class="docutils literal notranslate"><span class="pre">subtemplate.html</span></code> that reads:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">cycle</span> <span class="s1">&#39;even&#39;</span> <span class="s1">&#39;odd&#39;</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>Using the non-thread-safe, pre-Django 1.2 renderer, this would output:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">even</span> <span class="n">odd</span> <span class="n">even</span> <span class="n">odd</span> <span class="o">...</span>
</pre></div>
</div>
<p>Using the thread-safe Django 1.2 renderer, you will instead get:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">even</span> <span class="n">even</span> <span class="n">even</span> <span class="n">even</span> <span class="o">...</span>
</pre></div>
</div>
<p>This is because each rendering of the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">include</span></code></a> tag is an
independent rendering. When the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">cycle</span></code></a> tag was not thread safe,
the state of the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">cycle</span></code></a> tag would leak between multiple
renderings of the same <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">include</span></code></a>. Now that the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-cycle"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">cycle</span></code></a> tag
is thread safe, this leakage no longer occurs.</p>
</div>
<div class="section" id="s-user-passes-test-login-required-and-permission-required">
<span id="s-user-passes-test-login-required-permission-required"></span><span id="user-passes-test-login-required-and-permission-required"></span><span id="user-passes-test-login-required-permission-required"></span><h3><code class="docutils literal notranslate"><span class="pre">user_passes_test</span></code>, <code class="docutils literal notranslate"><span class="pre">login_required</span></code> and <code class="docutils literal notranslate"><span class="pre">permission_required</span></code><a class="headerlink" href="#user-passes-test-login-required-and-permission-required" title="永久链接至标题">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">django.contrib.auth.decorators</span></code> provides the decorators
<code class="docutils literal notranslate"><span class="pre">login_required</span></code>, <code class="docutils literal notranslate"><span class="pre">permission_required</span></code> and
<code class="docutils literal notranslate"><span class="pre">user_passes_test</span></code>. Previously it was possible to use these
decorators both on functions (where the first argument is 'request')
and on methods (where the first argument is 'self', and the second
argument is 'request'). Unfortunately, flaws were discovered in the
code supporting this: it only works in limited circumstances, and
produces errors that are very difficult to debug when it does not
work.</p>
<p>For this reason, the 'auto adapt' behavior has been removed, and if
you are using these decorators on methods, you will need to manually
apply <a class="reference internal" href="../ref/utils.html#django.utils.decorators.method_decorator" title="django.utils.decorators.method_decorator"><code class="xref py py-func docutils literal notranslate"><span class="pre">django.utils.decorators.method_decorator()</span></code></a> to convert the
decorator to one that works with methods. For example, you would
change code from this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">MyClass</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>

    <span class="nd">@login_required</span>
    <span class="k">def</span> <span class="nf">my_view</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">):</span>
        <span class="k">pass</span>
</pre></div>
</div>
<p>改成这个：</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils.decorators</span> <span class="kn">import</span> <span class="n">method_decorator</span>

<span class="k">class</span> <span class="nc">MyClass</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>

    <span class="nd">@method_decorator</span><span class="p">(</span><span class="n">login_required</span><span class="p">)</span>
    <span class="k">def</span> <span class="nf">my_view</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">):</span>
        <span class="k">pass</span>
</pre></div>
</div>
<p>或者：</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils.decorators</span> <span class="kn">import</span> <span class="n">method_decorator</span>

<span class="n">login_required_m</span> <span class="o">=</span> <span class="n">method_decorator</span><span class="p">(</span><span class="n">login_required</span><span class="p">)</span>

<span class="k">class</span> <span class="nc">MyClass</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>

    <span class="nd">@login_required_m</span>
    <span class="k">def</span> <span class="nf">my_view</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">):</span>
        <span class="k">pass</span>
</pre></div>
</div>
<p>For those of you who've been following the development trunk, this
change also applies to other decorators introduced since 1.1,
including <code class="docutils literal notranslate"><span class="pre">csrf_protect</span></code>, <code class="docutils literal notranslate"><span class="pre">cache_control</span></code> and anything created
using <code class="docutils literal notranslate"><span class="pre">decorator_from_middleware</span></code>.</p>
</div>
<div class="section" id="s-if-tag-changes">
<span id="if-tag-changes"></span><h3><a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">if</span></code></a> tag changes<a class="headerlink" href="#if-tag-changes" title="永久链接至标题">¶</a></h3>
<p>Due to new features in the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-if"><code class="xref std std-ttag docutils literal notranslate"><span class="pre">if</span></code></a> template tag, it no longer
accepts 'and', 'or' and 'not' as valid <strong>variable</strong> names. Previously,
these strings could be used as variable names. Now, the keyword status
is always enforced, and template code such as <code class="docutils literal notranslate"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">not</span> <span class="pre">%}</span></code> or <code class="docutils literal notranslate"><span class="pre">{%</span>
<span class="pre">if</span> <span class="pre">and</span> <span class="pre">%}</span></code> will throw a <code class="docutils literal notranslate"><span class="pre">TemplateSyntaxError</span></code>. Also, <code class="docutils literal notranslate"><span class="pre">in</span></code> is a
new keyword and so is not a valid variable name in this tag.</p>
</div>
<div class="section" id="s-lazyobject">
<span id="lazyobject"></span><h3><code class="docutils literal notranslate"><span class="pre">LazyObject</span></code><a class="headerlink" href="#lazyobject" title="永久链接至标题">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">LazyObject</span></code> is an undocumented-but-often-used utility class used for lazily
wrapping other objects of unknown type.</p>
<p>In Django 1.1 and earlier, it handled introspection in a non-standard way,
depending on wrapped objects implementing a public method named
<code class="docutils literal notranslate"><span class="pre">get_all_members()</span></code>. Since this could easily lead to name clashes, it has been
changed to use the standard Python introspection method, involving
<code class="docutils literal notranslate"><span class="pre">__members__</span></code> and <code class="docutils literal notranslate"><span class="pre">__dir__()</span></code>.</p>
<p>If you used <code class="docutils literal notranslate"><span class="pre">LazyObject</span></code> in your own code
and implemented the <code class="docutils literal notranslate"><span class="pre">get_all_members()</span></code> method for wrapped objects, you'll need
to make a couple of changes:</p>
<p>First, if your class does not have special requirements for introspection (i.e.,
you have not implemented <code class="docutils literal notranslate"><span class="pre">__getattr__()</span></code> or other methods that allow for
attributes not discoverable by normal mechanisms), you can simply remove the
<code class="docutils literal notranslate"><span class="pre">get_all_members()</span></code> method. The default implementation on <code class="docutils literal notranslate"><span class="pre">LazyObject</span></code> will
do the right thing.</p>
<p>If you have more complex requirements for introspection, first rename the
<code class="docutils literal notranslate"><span class="pre">get_all_members()</span></code> method to <code class="docutils literal notranslate"><span class="pre">__dir__()</span></code>. This is the standard
introspection method for Python 2.6 and above. If you require support for Python
versions earlier than 2.6, add the following code to the class:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">__members__</span> <span class="o">=</span> <span class="nb">property</span><span class="p">(</span><span class="k">lambda</span> <span class="bp">self</span><span class="p">:</span> <span class="bp">self</span><span class="o">.</span><span class="fm">__dir__</span><span class="p">())</span>
</pre></div>
</div>
</div>
<div class="section" id="s-dict-on-model-instances">
<span id="dict-on-model-instances"></span><h3><code class="docutils literal notranslate"><span class="pre">__dict__</span></code> on model instances<a class="headerlink" href="#dict-on-model-instances" title="永久链接至标题">¶</a></h3>
<p>Historically, the <code class="docutils literal notranslate"><span class="pre">__dict__</span></code> attribute of a model instance has only contained
attributes corresponding to the fields on a model.</p>
<p>In order to support multiple database configurations, Django 1.2 has
added a <code class="docutils literal notranslate"><span class="pre">_state</span></code> attribute to object instances. This attribute will
appear in <code class="docutils literal notranslate"><span class="pre">__dict__</span></code> for a model instance. If your code relies on
iterating over <code class="docutils literal notranslate"><span class="pre">__dict__</span></code> to obtain a list of fields, you must now
be prepared to handle or filter out the <code class="docutils literal notranslate"><span class="pre">_state</span></code> attribute.</p>
</div>
<div class="section" id="s-test-runner-exit-status-code">
<span id="test-runner-exit-status-code"></span><h3>Test runner exit status code<a class="headerlink" href="#test-runner-exit-status-code" title="永久链接至标题">¶</a></h3>
<p>The exit status code of the test runners (<code class="docutils literal notranslate"><span class="pre">tests/runtests.py</span></code> and <code class="docutils literal notranslate"><span class="pre">python</span>
<span class="pre">manage.py</span> <span class="pre">test</span></code>) no longer represents the number of failed tests, because a
failure of 256 or more tests resulted in a wrong exit status code. The exit
status code for the test runner is now 0 for success (no failing tests) and 1
for any number of test failures. If needed, the number of test failures can be
found at the end of the test runner's output.</p>
</div>
<div class="section" id="s-cookie-encoding">
<span id="cookie-encoding"></span><h3>Cookie encoding<a class="headerlink" href="#cookie-encoding" title="永久链接至标题">¶</a></h3>
<p>To fix bugs with cookies in Internet Explorer, Safari, and possibly
other browsers, our encoding of cookie values was changed so that the
comma and semicolon are treated as non-safe characters, and are
therefore encoded as <code class="docutils literal notranslate"><span class="pre">\054</span></code> and <code class="docutils literal notranslate"><span class="pre">\073</span></code> respectively.  This could
produce backwards incompatibilities, especially if you are storing
comma or semi-colon in cookies and have JavaScript code that parses
and manipulates cookie values client-side.</p>
</div>
<div class="section" id="s-modelform-is-valid-and-modelform-errors">
<span id="modelform-is-valid-and-modelform-errors"></span><h3><code class="docutils literal notranslate"><span class="pre">ModelForm.is_valid()</span></code> and <code class="docutils literal notranslate"><span class="pre">ModelForm.errors</span></code><a class="headerlink" href="#modelform-is-valid-and-modelform-errors" title="永久链接至标题">¶</a></h3>
<p>Much of the validation work for ModelForms has been moved down to the model
level. As a result, the first time you call <code class="docutils literal notranslate"><span class="pre">ModelForm.is_valid()</span></code>, access
<code class="docutils literal notranslate"><span class="pre">ModelForm.errors</span></code> or otherwise trigger form validation, your model will be
cleaned in-place. This conversion used to happen when the model was saved. If
you need an unmodified instance of your model, you should pass a copy to the
<code class="docutils literal notranslate"><span class="pre">ModelForm</span></code> constructor.</p>
</div>
<div class="section" id="s-booleanfield-on-mysql">
<span id="booleanfield-on-mysql"></span><h3><code class="docutils literal notranslate"><span class="pre">BooleanField</span></code> on MySQL<a class="headerlink" href="#booleanfield-on-mysql" title="永久链接至标题">¶</a></h3>
<p>In previous versions of Django, a model's <code class="docutils literal notranslate"><span class="pre">BooleanField</span></code> under MySQL
would return its value as either <code class="docutils literal notranslate"><span class="pre">1</span></code> or <code class="docutils literal notranslate"><span class="pre">0</span></code>, instead of <code class="docutils literal notranslate"><span class="pre">True</span></code>
or <code class="docutils literal notranslate"><span class="pre">False</span></code>; for most people this wasn't a problem because <code class="docutils literal notranslate"><span class="pre">bool</span></code>
is a subclass of <code class="docutils literal notranslate"><span class="pre">int</span></code> in Python. In Django 1.2, however,
<code class="docutils literal notranslate"><span class="pre">BooleanField</span></code> on MySQL correctly returns a real <code class="docutils literal notranslate"><span class="pre">bool</span></code>.  The only
time this should ever be an issue is if you were expecting the
<code class="docutils literal notranslate"><span class="pre">repr</span></code> of a <code class="docutils literal notranslate"><span class="pre">BooleanField</span></code> to print <code class="docutils literal notranslate"><span class="pre">1</span></code> or <code class="docutils literal notranslate"><span class="pre">0</span></code>.</p>
</div>
<div class="section" id="s-changes-to-the-interpretation-of-max-num-in-formsets">
<span id="changes-to-the-interpretation-of-max-num-in-formsets"></span><h3>Changes to the interpretation of <code class="docutils literal notranslate"><span class="pre">max_num</span></code> in FormSets<a class="headerlink" href="#changes-to-the-interpretation-of-max-num-in-formsets" title="永久链接至标题">¶</a></h3>
<p>As part of enhancements made to the handling of FormSets, the default
value and interpretation of the <code class="docutils literal notranslate"><span class="pre">max_num</span></code> parameter to the
<a class="reference internal" href="../topics/forms/formsets.html#formsets-max-num"><span class="std std-ref">django.forms.formsets.formset_factory()</span></a> and
<a class="reference internal" href="../topics/forms/modelforms.html#model-formsets-max-num"><span class="std std-ref">django.forms.models.modelformset_factory()</span></a> functions has changed slightly. This
change also affects the way the
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.InlineModelAdmin.max_num" title="django.contrib.admin.InlineModelAdmin.max_num"><code class="xref py py-attr docutils literal notranslate"><span class="pre">max_num</span></code></a> argument is used for
inline admin objects.</p>
<p>Previously, the default value for <code class="docutils literal notranslate"><span class="pre">max_num</span></code> was <code class="docutils literal notranslate"><span class="pre">0</span></code> (zero).
FormSets then used the boolean value of <code class="docutils literal notranslate"><span class="pre">max_num</span></code> to determine if a
limit was to be imposed on the number of generated forms. The default
value of <code class="docutils literal notranslate"><span class="pre">0</span></code> meant that there was no default limit on the number of
forms in a FormSet.</p>
<p>Starting with 1.2, the default value for <code class="docutils literal notranslate"><span class="pre">max_num</span></code> has been changed
to <code class="docutils literal notranslate"><span class="pre">None</span></code>, and FormSets will differentiate between a value of
<code class="docutils literal notranslate"><span class="pre">None</span></code> and a value of <code class="docutils literal notranslate"><span class="pre">0</span></code>. A value of <code class="docutils literal notranslate"><span class="pre">None</span></code> indicates that no
limit on the number of forms is to be imposed; a value of <code class="docutils literal notranslate"><span class="pre">0</span></code>
indicates that a maximum of 0 forms should be imposed. This doesn't
necessarily mean that no forms will be displayed -- see the
<a class="reference internal" href="../topics/forms/modelforms.html#model-formsets-max-num"><span class="std std-ref">ModelFormSet documentation</span></a> for more
details.</p>
<p>If you were manually specifying a value of <code class="docutils literal notranslate"><span class="pre">0</span></code> for <code class="docutils literal notranslate"><span class="pre">max_num</span></code>, you
will need to update your FormSet and/or admin definitions.</p>
<div class="admonition seealso">
<p class="first admonition-title">参见</p>
<p class="last"><a class="reference internal" href="#js-assisted-inlines"><span class="std std-ref">JavaScript-assisted handling of inline related objects in the admin</span></a></p>
</div>
</div>
<div class="section" id="s-email-re">
<span id="email-re"></span><h3><code class="docutils literal notranslate"><span class="pre">email_re</span></code><a class="headerlink" href="#email-re" title="永久链接至标题">¶</a></h3>
<p>An undocumented regular expression for validating email addresses has been moved
from <code class="docutils literal notranslate"><span class="pre">django.form.fields</span></code> to <code class="docutils literal notranslate"><span class="pre">django.core.validators</span></code>. You will need to
update your imports if you are using it.</p>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-2">
<span id="s-deprecated-features-1-2"></span><span id="features-deprecated-in-1-2"></span><span id="deprecated-features-1-2"></span><h2>在 1.2 中被废弃的功能<a class="headerlink" href="#features-deprecated-in-1-2" title="永久链接至标题">¶</a></h2>
<p>Finally, Django 1.2 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.</p>
<p>Code taking advantage of any of the features below will raise a
<code class="docutils literal notranslate"><span class="pre">PendingDeprecationWarning</span></code> in Django 1.2. This warning will be
silent by default, but may be turned on using Python's <a class="reference external" href="https://docs.python.org/3/library/warnings.html#module-warnings" title="(在 Python v3.10)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">warnings</span></code></a>
module, or by running Python with a <code class="docutils literal notranslate"><span class="pre">-Wd</span></code> or <code class="docutils literal notranslate"><span class="pre">-Wall</span></code> flag.</p>
<p>In Django 1.3, these warnings will become a <code class="docutils literal notranslate"><span class="pre">DeprecationWarning</span></code>,
which is <em>not</em> silent. In Django 1.4 support for these features will
be removed entirely.</p>
<div class="admonition seealso">
<p class="first admonition-title">参见</p>
<p class="last">For more details, see the documentation <a class="reference internal" href="../internals/release-process.html"><span class="doc">Django's release process</span></a> and our <a class="reference internal" href="../internals/deprecation.html"><span class="doc">deprecation timeline</span></a>.`</p>
</div>
<div class="section" id="s-specifying-databases">
<span id="s-id5"></span><span id="specifying-databases"></span><span id="id5"></span><h3>Specifying databases<a class="headerlink" href="#specifying-databases" title="永久链接至标题">¶</a></h3>
<p>Prior to Django 1.2, Django used a number of settings to control
access to a single database. Django 1.2 introduces support for
multiple databases, and as a result the way you define database
settings has changed.</p>
<p>Any existing Django settings file will continue to work as expected
until Django 1.4. Until then, old-style database settings will be
automatically translated to the new-style format.</p>
<p>In the old-style (pre 1.2) format, you had a number of <code class="docutils literal notranslate"><span class="pre">DATABASE_</span></code>
settings in your settings file. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">DATABASE_NAME</span> <span class="o">=</span> <span class="s1">&#39;test_db&#39;</span>
<span class="n">DATABASE_ENGINE</span> <span class="o">=</span> <span class="s1">&#39;postgresql_psycopg2&#39;</span>
<span class="n">DATABASE_USER</span> <span class="o">=</span> <span class="s1">&#39;myusername&#39;</span>
<span class="n">DATABASE_PASSWORD</span> <span class="o">=</span> <span class="s1">&#39;s3krit&#39;</span>
</pre></div>
</div>
<p>These settings are now in a dictionary named
<a class="reference internal" href="../ref/settings.html#std:setting-DATABASES"><code class="xref std std-setting docutils literal notranslate"><span class="pre">DATABASES</span></code></a>. Each item in the dictionary corresponds to a
single database connection, with the name <code class="docutils literal notranslate"><span class="pre">'default'</span></code> describing the
default database connection. The setting names have also been
shortened. The previous sample settings would now look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">DATABASES</span> <span class="o">=</span> <span class="p">{</span>
    <span class="s1">&#39;default&#39;</span><span class="p">:</span> <span class="p">{</span>
        <span class="s1">&#39;NAME&#39;</span><span class="p">:</span> <span class="s1">&#39;test_db&#39;</span><span class="p">,</span>
        <span class="s1">&#39;ENGINE&#39;</span><span class="p">:</span> <span class="s1">&#39;django.db.backends.postgresql_psycopg2&#39;</span><span class="p">,</span>
        <span class="s1">&#39;USER&#39;</span><span class="p">:</span> <span class="s1">&#39;myusername&#39;</span><span class="p">,</span>
        <span class="s1">&#39;PASSWORD&#39;</span><span class="p">:</span> <span class="s1">&#39;s3krit&#39;</span><span class="p">,</span>
    <span class="p">}</span>
<span class="p">}</span>
</pre></div>
</div>
<p>This affects the following settings:</p>
<table class="docutils">
<colgroup>
<col width="54%" />
<col width="46%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Old setting</th>
<th class="head">New Setting</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_ENGINE</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-ENGINE"><code class="xref std std-setting docutils literal notranslate"><span class="pre">ENGINE</span></code></a></td>
</tr>
<tr class="row-odd"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_HOST</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-HOST"><code class="xref std std-setting docutils literal notranslate"><span class="pre">HOST</span></code></a></td>
</tr>
<tr class="row-even"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_NAME</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-NAME"><code class="xref std std-setting docutils literal notranslate"><span class="pre">NAME</span></code></a></td>
</tr>
<tr class="row-odd"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_OPTIONS</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-OPTIONS"><code class="xref std std-setting docutils literal notranslate"><span class="pre">OPTIONS</span></code></a></td>
</tr>
<tr class="row-even"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_PASSWORD</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-PASSWORD"><code class="xref std std-setting docutils literal notranslate"><span class="pre">PASSWORD</span></code></a></td>
</tr>
<tr class="row-odd"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_PORT</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-PORT"><code class="xref std std-setting docutils literal notranslate"><span class="pre">PORT</span></code></a></td>
</tr>
<tr class="row-even"><td><code class="docutils literal notranslate"><span class="pre">DATABASE_USER</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-USER"><code class="xref std std-setting docutils literal notranslate"><span class="pre">USER</span></code></a></td>
</tr>
<tr class="row-odd"><td><code class="docutils literal notranslate"><span class="pre">TEST_DATABASE_CHARSET</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_CHARSET"><code class="xref std std-setting docutils literal notranslate"><span class="pre">TEST_CHARSET</span></code></a></td>
</tr>
<tr class="row-even"><td><code class="docutils literal notranslate"><span class="pre">TEST_DATABASE_COLLATION</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_COLLATION"><code class="xref std std-setting docutils literal notranslate"><span class="pre">TEST_COLLATION</span></code></a></td>
</tr>
<tr class="row-odd"><td><code class="docutils literal notranslate"><span class="pre">TEST_DATABASE_NAME</span></code></td>
<td><a class="reference internal" href="../ref/settings.html#std:setting-TEST_NAME"><code class="xref std std-setting docutils literal notranslate"><span class="pre">TEST_NAME</span></code></a></td>
</tr>
</tbody>
</table>
<p>These changes are also required if you have manually created a database
connection using <code class="docutils literal notranslate"><span class="pre">DatabaseWrapper()</span></code> from your database backend of choice.</p>
<p>In addition to the change in structure, Django 1.2 removes the special
handling for the built-in database backends. All database backends
must now be specified by a fully qualified module name (i.e.,
<code class="docutils literal notranslate"><span class="pre">django.db.backends.postgresql_psycopg2</span></code>, rather than just
<code class="docutils literal notranslate"><span class="pre">postgresql_psycopg2</span></code>).</p>
</div>
<div class="section" id="s-postgresql-database-backend">
<span id="postgresql-database-backend"></span><h3><code class="docutils literal notranslate"><span class="pre">postgresql</span></code> database backend<a class="headerlink" href="#postgresql-database-backend" title="永久链接至标题">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">psycopg1</span></code> library has not been updated since October 2005. As a
result, the <code class="docutils literal notranslate"><span class="pre">postgresql</span></code> database backend, which uses this library,
has been deprecated.</p>
<p>If you are currently using the <code class="docutils literal notranslate"><span class="pre">postgresql</span></code> backend, you should
migrate to using the <code class="docutils literal notranslate"><span class="pre">postgresql_psycopg2</span></code> backend. To update your
code, install the <code class="docutils literal notranslate"><span class="pre">psycopg2</span></code> library and change the
<a class="reference internal" href="../ref/settings.html#std:setting-DATABASE-ENGINE"><code class="xref std std-setting docutils literal notranslate"><span class="pre">ENGINE</span></code></a> setting to use
<code class="docutils literal notranslate"><span class="pre">django.db.backends.postgresql_psycopg2</span></code>.</p>
</div>
<div class="section" id="s-csrf-response-rewriting-middleware">
<span id="csrf-response-rewriting-middleware"></span><h3>CSRF response-rewriting middleware<a class="headerlink" href="#csrf-response-rewriting-middleware" title="永久链接至标题">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">CsrfResponseMiddleware</span></code>, the middleware that automatically inserted
CSRF tokens into <code class="docutils literal notranslate"><span class="pre">POST</span></code> forms in outgoing pages, has been deprecated
in favor of a template tag method (see above), and will be removed
completely in Django 1.4. <code class="docutils literal notranslate"><span class="pre">CsrfMiddleware</span></code>, which includes the
functionality of <code class="docutils literal notranslate"><span class="pre">CsrfResponseMiddleware</span></code> and
<code class="docutils literal notranslate"><span class="pre">CsrfViewMiddleware</span></code>, has likewise been deprecated.</p>
<p>Also, the CSRF module has moved from contrib to core, and the old
imports are deprecated, as described in the upgrading notes.</p>
<div class="admonition-documentation-removed admonition">
<p class="first admonition-title">Documentation removed</p>
<p class="last">The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.</p>
</div>
</div>
<div class="section" id="s-smtpconnection">
<span id="smtpconnection"></span><h3><code class="docutils literal notranslate"><span class="pre">SMTPConnection</span></code><a class="headerlink" href="#smtpconnection" title="永久链接至标题">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">SMTPConnection</span></code> class has been deprecated in favor of a generic
email backend API. Old code that explicitly instantiated an instance
of an SMTPConnection:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">SMTPConnection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">SMTPConnection</span><span class="p">()</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>...should now call <a class="reference internal" href="../topics/email.html#django.core.mail.get_connection" title="django.core.mail.get_connection"><code class="xref py py-meth docutils literal notranslate"><span class="pre">get_connection()</span></code></a> to
instantiate a generic email connection:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">get_connection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">()</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>Depending on the value of the <a class="reference internal" href="../ref/settings.html#std:setting-EMAIL_BACKEND"><code class="xref std std-setting docutils literal notranslate"><span class="pre">EMAIL_BACKEND</span></code></a> setting, this
may not return an SMTP connection. If you explicitly require an SMTP
connection with which to send email, you can explicitly request an
SMTP connection:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.core.mail</span> <span class="kn">import</span> <span class="n">get_connection</span>
<span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">(</span><span class="s1">&#39;django.core.mail.backends.smtp.EmailBackend&#39;</span><span class="p">)</span>
<span class="n">messages</span> <span class="o">=</span> <span class="n">get_notification_email</span><span class="p">()</span>
<span class="n">connection</span><span class="o">.</span><span class="n">send_messages</span><span class="p">(</span><span class="n">messages</span><span class="p">)</span>
</pre></div>
</div>
<p>If your call to construct an instance of <code class="docutils literal notranslate"><span class="pre">SMTPConnection</span></code> required
additional arguments, those arguments can be passed to the
<a class="reference internal" href="../topics/email.html#django.core.mail.get_connection" title="django.core.mail.get_connection"><code class="xref py py-meth docutils literal notranslate"><span class="pre">get_connection()</span></code></a> call:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">connection</span> <span class="o">=</span> <span class="n">get_connection</span><span class="p">(</span><span class="s1">&#39;django.core.mail.backends.smtp.EmailBackend&#39;</span><span class="p">,</span> <span class="n">hostname</span><span class="o">=</span><span class="s1">&#39;localhost&#39;</span><span class="p">,</span> <span class="n">port</span><span class="o">=</span><span class="mi">1234</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-user-messages-api">
<span id="user-messages-api"></span><h3>User Messages API<a class="headerlink" href="#user-messages-api" title="永久链接至标题">¶</a></h3>
<p>The API for storing messages in the user <code class="docutils literal notranslate"><span class="pre">Message</span></code> model (via
<code class="docutils literal notranslate"><span class="pre">user.message_set.create</span></code>) is now deprecated and will be removed in Django
1.4 according to the standard <a class="reference internal" href="../internals/release-process.html"><span class="doc">release process</span></a>.</p>
<p>To upgrade your code, you need to replace any instances of this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">user</span><span class="o">.</span><span class="n">message_set</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="s1">&#39;a message&#39;</span><span class="p">)</span>
</pre></div>
</div>
<p>...with the following:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">messages</span>
<span class="n">messages</span><span class="o">.</span><span class="n">add_message</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">messages</span><span class="o">.</span><span class="n">INFO</span><span class="p">,</span> <span class="s1">&#39;a message&#39;</span><span class="p">)</span>
</pre></div>
</div>
<p>Additionally, if you make use of the method, you need to replace the
following:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">message</span> <span class="ow">in</span> <span class="n">user</span><span class="o">.</span><span class="n">get_and_delete_messages</span><span class="p">():</span>
    <span class="o">...</span>
</pre></div>
</div>
<p>...with:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.contrib</span> <span class="kn">import</span> <span class="n">messages</span>
<span class="k">for</span> <span class="n">message</span> <span class="ow">in</span> <span class="n">messages</span><span class="o">.</span><span class="n">get_messages</span><span class="p">(</span><span class="n">request</span><span class="p">):</span>
    <span class="o">...</span>
</pre></div>
</div>
<p>For more information, see the full
<a class="reference internal" href="../ref/contrib/messages.html"><span class="doc">messages documentation</span></a>. You should begin to
update your code to use the new API immediately.</p>
</div>
<div class="section" id="s-date-format-helper-functions">
<span id="date-format-helper-functions"></span><h3>Date format helper functions<a class="headerlink" href="#date-format-helper-functions" title="永久链接至标题">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">django.utils.translation.get_date_formats()</span></code> and
<code class="docutils literal notranslate"><span class="pre">django.utils.translation.get_partial_date_formats()</span></code> have been deprecated
in favor of the appropriate calls to <code class="docutils literal notranslate"><span class="pre">django.utils.formats.get_format()</span></code>,
which is locale-aware when <a class="reference internal" href="../ref/settings.html#std:setting-USE_L10N"><code class="xref std std-setting docutils literal notranslate"><span class="pre">USE_L10N</span></code></a> is set to <code class="docutils literal notranslate"><span class="pre">True</span></code>, and falls
back to default settings if set to <code class="docutils literal notranslate"><span class="pre">False</span></code>.</p>
<p>To get the different date formats, instead of writing this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils.translation</span> <span class="kn">import</span> <span class="n">get_date_formats</span>
<span class="n">date_format</span><span class="p">,</span> <span class="n">datetime_format</span><span class="p">,</span> <span class="n">time_format</span> <span class="o">=</span> <span class="n">get_date_formats</span><span class="p">()</span>
</pre></div>
</div>
<p>...use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">formats</span>
<span class="n">date_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s1">&#39;DATE_FORMAT&#39;</span><span class="p">)</span>
<span class="n">datetime_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s1">&#39;DATETIME_FORMAT&#39;</span><span class="p">)</span>
<span class="n">time_format</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">get_format</span><span class="p">(</span><span class="s1">&#39;TIME_FORMAT&#39;</span><span class="p">)</span>
</pre></div>
</div>
<p>Or, when directly formatting a date value:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">formats</span>
<span class="n">value_formatted</span> <span class="o">=</span> <span class="n">formats</span><span class="o">.</span><span class="n">date_format</span><span class="p">(</span><span class="n">value</span><span class="p">,</span> <span class="s1">&#39;DATETIME_FORMAT&#39;</span><span class="p">)</span>
</pre></div>
</div>
<p>The same applies to the globals found in <code class="docutils literal notranslate"><span class="pre">django.forms.fields</span></code>:</p>
<ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">DEFAULT_DATE_INPUT_FORMATS</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">DEFAULT_TIME_INPUT_FORMATS</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">DEFAULT_DATETIME_INPUT_FORMATS</span></code></li>
</ul>
<p>Use <code class="docutils literal notranslate"><span class="pre">django.utils.formats.get_format()</span></code> to get the appropriate formats.</p>
</div>
<div class="section" id="s-function-based-test-runners">
<span id="function-based-test-runners"></span><h3>Function-based test runners<a class="headerlink" href="#function-based-test-runners" title="永久链接至标题">¶</a></h3>
<p>Django 1.2 changes the test runner tools to use a class-based
approach. Old style function-based test runners will still work, but
should be updated to use the new <a class="reference internal" href="../topics/testing/advanced.html#topics-testing-test-runner"><span class="std std-ref">class-based runners</span></a>.</p>
</div>
<div class="section" id="s-feed-in-django-contrib-syndication-feeds">
<span id="s-updating-feeds"></span><span id="feed-in-django-contrib-syndication-feeds"></span><span id="updating-feeds"></span><h3><code class="docutils literal notranslate"><span class="pre">Feed</span></code> in <code class="docutils literal notranslate"><span class="pre">django.contrib.syndication.feeds</span></code><a class="headerlink" href="#feed-in-django-contrib-syndication-feeds" title="永久链接至标题">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">django.contrib.syndication.feeds.Feed</span></code> class has been
replaced by the <a class="reference internal" href="../ref/contrib/syndication.html#django.contrib.syndication.views.Feed" title="django.contrib.syndication.views.Feed"><code class="xref py py-class docutils literal notranslate"><span class="pre">django.contrib.syndication.views.Feed</span></code></a> class.
The old <code class="docutils literal notranslate"><span class="pre">feeds.Feed</span></code> class is deprecated, and will be removed in
Django 1.4.</p>
<p>The new class has an almost identical API, but allows instances to be
used as views. For example, consider the use of the old framework in
the following <a class="reference internal" href="../topics/http/urls.html"><span class="doc">URLconf</span></a>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.conf.urls.defaults</span> <span class="kn">import</span> <span class="o">*</span>
<span class="kn">from</span> <span class="nn">myproject.feeds</span> <span class="kn">import</span> <span class="n">LatestEntries</span><span class="p">,</span> <span class="n">LatestEntriesByCategory</span>

<span class="n">feeds</span> <span class="o">=</span> <span class="p">{</span>
    <span class="s1">&#39;latest&#39;</span><span class="p">:</span> <span class="n">LatestEntries</span><span class="p">,</span>
    <span class="s1">&#39;categories&#39;</span><span class="p">:</span> <span class="n">LatestEntriesByCategory</span><span class="p">,</span>
<span class="p">}</span>

<span class="n">urlpatterns</span> <span class="o">=</span> <span class="n">patterns</span><span class="p">(</span><span class="s1">&#39;&#39;</span><span class="p">,</span>
    <span class="c1"># ...</span>
    <span class="p">(</span><span class="sa">r</span><span class="s1">&#39;^feeds/(?P&lt;url&gt;.*)/$&#39;</span><span class="p">,</span> <span class="s1">&#39;django.contrib.syndication.views.feed&#39;</span><span class="p">,</span>
        <span class="p">{</span><span class="s1">&#39;feed_dict&#39;</span><span class="p">:</span> <span class="n">feeds</span><span class="p">}),</span>
    <span class="c1"># ...</span>
<span class="p">)</span>
</pre></div>
</div>
<p>Using the new Feed class, these feeds can be deployed directly as views:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.conf.urls.defaults</span> <span class="kn">import</span> <span class="o">*</span>
<span class="kn">from</span> <span class="nn">myproject.feeds</span> <span class="kn">import</span> <span class="n">LatestEntries</span><span class="p">,</span> <span class="n">LatestEntriesByCategory</span>

<span class="n">urlpatterns</span> <span class="o">=</span> <span class="n">patterns</span><span class="p">(</span><span class="s1">&#39;&#39;</span><span class="p">,</span>
    <span class="c1"># ...</span>
    <span class="p">(</span><span class="sa">r</span><span class="s1">&#39;^feeds/latest/$&#39;</span><span class="p">,</span> <span class="n">LatestEntries</span><span class="p">()),</span>
    <span class="p">(</span><span class="sa">r</span><span class="s1">&#39;^feeds/categories/(?P&lt;category_id&gt;\d+)/$&#39;</span><span class="p">,</span> <span class="n">LatestEntriesByCategory</span><span class="p">()),</span>
    <span class="c1"># ...</span>
<span class="p">)</span>
</pre></div>
</div>
<p>If you currently use the <code class="docutils literal notranslate"><span class="pre">feed()</span></code> view, the <code class="docutils literal notranslate"><span class="pre">LatestEntries</span></code> class would
often not need to be modified apart from subclassing the new
<a class="reference internal" href="../ref/contrib/syndication.html#django.contrib.syndication.views.Feed" title="django.contrib.syndication.views.Feed"><code class="xref py py-class docutils literal notranslate"><span class="pre">Feed</span></code></a> class. The exception is if
Django was automatically working out the name of the template to use to render
the feed's description and title elements (if you were not specifying the
<code class="docutils literal notranslate"><span class="pre">title_template</span></code> and <code class="docutils literal notranslate"><span class="pre">description_template</span></code> attributes). You should ensure
that you always specify <code class="docutils literal notranslate"><span class="pre">title_template</span></code> and <code class="docutils literal notranslate"><span class="pre">description_template</span></code>
attributes, or provide <code class="docutils literal notranslate"><span class="pre">item_title()</span></code> and <code class="docutils literal notranslate"><span class="pre">item_description()</span></code> methods.</p>
<p>However, <code class="docutils literal notranslate"><span class="pre">LatestEntriesByCategory</span></code> uses the <code class="docutils literal notranslate"><span class="pre">get_object()</span></code> method
with the <code class="docutils literal notranslate"><span class="pre">bits</span></code> argument to specify a specific category to show. In
the new <a class="reference internal" href="../ref/contrib/syndication.html#django.contrib.syndication.views.Feed" title="django.contrib.syndication.views.Feed"><code class="xref py py-class docutils literal notranslate"><span class="pre">Feed</span></code></a> class,
<code class="docutils literal notranslate"><span class="pre">get_object()</span></code> method takes a <code class="docutils literal notranslate"><span class="pre">request</span></code> and arguments from the
URL, so it would look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.contrib.syndication.views</span> <span class="kn">import</span> <span class="n">Feed</span>
<span class="kn">from</span> <span class="nn">django.shortcuts</span> <span class="kn">import</span> <span class="n">get_object_or_404</span>
<span class="kn">from</span> <span class="nn">myproject.models</span> <span class="kn">import</span> <span class="n">Category</span>

<span class="k">class</span> <span class="nc">LatestEntriesByCategory</span><span class="p">(</span><span class="n">Feed</span><span class="p">):</span>
    <span class="k">def</span> <span class="nf">get_object</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">request</span><span class="p">,</span> <span class="n">category_id</span><span class="p">):</span>
        <span class="k">return</span> <span class="n">get_object_or_404</span><span class="p">(</span><span class="n">Category</span><span class="p">,</span> <span class="nb">id</span><span class="o">=</span><span class="n">category_id</span><span class="p">)</span>

    <span class="c1"># ...</span>
</pre></div>
</div>
<p>Additionally, the <code class="docutils literal notranslate"><span class="pre">get_feed()</span></code> method on <code class="docutils literal notranslate"><span class="pre">Feed</span></code> classes now take
different arguments, which may impact you if you use the <code class="docutils literal notranslate"><span class="pre">Feed</span></code>
classes directly. Instead of just taking an optional <code class="docutils literal notranslate"><span class="pre">url</span></code> argument,
it now takes two arguments: the object returned by its own
<code class="docutils literal notranslate"><span class="pre">get_object()</span></code> method, and the current <code class="docutils literal notranslate"><span class="pre">request</span></code> object.</p>
<p>To take into account <code class="docutils literal notranslate"><span class="pre">Feed</span></code> classes not being initialized for each
request, the <code class="docutils literal notranslate"><span class="pre">__init__()</span></code> method now takes no arguments by default.
Previously it would have taken the <code class="docutils literal notranslate"><span class="pre">slug</span></code> from the URL and the
<code class="docutils literal notranslate"><span class="pre">request</span></code> object.</p>
<p>In accordance with <a class="reference external" href="https://www.rssboard.org/rss-profile">RSS best practices</a>, RSS feeds will now include
an <code class="docutils literal notranslate"><span class="pre">atom:link</span></code> element. You may need to update your tests to take
this into account.</p>
<p>For more information, see the full <a class="reference internal" href="../ref/contrib/syndication.html"><span class="doc">syndication framework
documentation</span></a>.</p>
</div>
<div class="section" id="s-technical-message-ids">
<span id="technical-message-ids"></span><h3>Technical message IDs<a class="headerlink" href="#technical-message-ids" title="永久链接至标题">¶</a></h3>
<p>Up to version 1.1 Django used technical message IDs
to provide localizers the possibility to translate date and time formats. They
were translatable <a class="reference internal" href="../topics/i18n/index.html#term-translation-string"><span class="xref std std-term">translation strings</span></a> that could
be recognized because they were all upper case (for example
<a class="reference internal" href="../ref/settings.html#std:setting-DATETIME_FORMAT"><code class="xref std std-setting docutils literal notranslate"><span class="pre">DATETIME_FORMAT</span></code></a>, <a class="reference internal" href="../ref/settings.html#std:setting-DATE_FORMAT"><code class="xref std std-setting docutils literal notranslate"><span class="pre">DATE_FORMAT</span></code></a>, <a class="reference internal" href="../ref/settings.html#std:setting-TIME_FORMAT"><code class="xref std std-setting docutils literal notranslate"><span class="pre">TIME_FORMAT</span></code></a>).
They have been deprecated in favor of the new <a class="reference internal" href="../topics/i18n/formatting.html"><span class="doc">本地格式化</span></a>
infrastructure that allows localizers to specify that information in a
<code class="docutils literal notranslate"><span class="pre">formats.py</span></code> file in the corresponding <code class="docutils literal notranslate"><span class="pre">django/conf/locale/&lt;locale</span> <span class="pre">name&gt;/</span></code>
directory.</p>
</div>
<div class="section" id="s-id6">
<span id="id6"></span><h3>GeoDjango<a class="headerlink" href="#id6" title="永久链接至标题">¶</a></h3>
<p>To allow support for multiple databases, the GeoDjango database internals were
changed substantially.  The largest backwards-incompatible change is that
the module <code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backend</span></code> was renamed to
<a class="reference internal" href="../ref/contrib/gis/db-api.html#module-django.contrib.gis.db.backends" title="django.contrib.gis.db.backends: GeoDjango's spatial database backends."><code class="xref py py-mod docutils literal notranslate"><span class="pre">django.contrib.gis.db.backends</span></code></a>, where the full-fledged
<a class="reference internal" href="../ref/contrib/gis/db-api.html#spatial-backends"><span class="std std-ref">spatial database backends</span></a> now exist.  The
following sections provide information on the most-popular APIs that
were affected by these changes.</p>
<div class="section" id="s-spatialbackend">
<span id="spatialbackend"></span><h4><code class="docutils literal notranslate"><span class="pre">SpatialBackend</span></code><a class="headerlink" href="#spatialbackend" title="永久链接至标题">¶</a></h4>
<p>Prior to the creation of the separate spatial backends, the
<code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backend.SpatialBackend</span></code> object was
provided as an abstraction to introspect on the capabilities of
the spatial database.  All of the attributes and routines provided by
<code class="docutils literal notranslate"><span class="pre">SpatialBackend</span></code> are now a part of the <code class="docutils literal notranslate"><span class="pre">ops</span></code> attribute of the
database backend.</p>
<p>The old module <code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backend</span></code> is still provided
for backwards-compatibility access to a <code class="docutils literal notranslate"><span class="pre">SpatialBackend</span></code> object,
which is just an alias to the <code class="docutils literal notranslate"><span class="pre">ops</span></code> module of the
<em>default</em> spatial database connection.</p>
<p>Users that were relying on undocumented modules and objects
within <code class="docutils literal notranslate"><span class="pre">django.contrib.gis.db.backend</span></code>, rather the abstractions
provided by <code class="docutils literal notranslate"><span class="pre">SpatialBackend</span></code>, are required to modify their code.
For example, the following import which would work in 1.1 and
below:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.contrib.gis.db.backend.postgis</span> <span class="kn">import</span> <span class="n">PostGISAdaptor</span>
</pre></div>
</div>
<p>Would need to be changed:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">connection</span>
<span class="n">PostGISAdaptor</span> <span class="o">=</span> <span class="n">connection</span><span class="o">.</span><span class="n">ops</span><span class="o">.</span><span class="n">Adapter</span>
</pre></div>
</div>
</div>
<div class="section" id="s-spatialrefsys-and-geometrycolumns-models">
<span id="spatialrefsys-and-geometrycolumns-models"></span><h4><code class="docutils literal notranslate"><span class="pre">SpatialRefSys</span></code> and <code class="docutils literal notranslate"><span class="pre">GeometryColumns</span></code> models<a class="headerlink" href="#spatialrefsys-and-geometrycolumns-models" title="永久链接至标题">¶</a></h4>
<p>In previous versions of GeoDjango, <a class="reference internal" href="../ref/contrib/gis/model-api.html#module-django.contrib.gis.db.models" title="django.contrib.gis.db.models: GeoDjango model and field API."><code class="xref py py-mod docutils literal notranslate"><span class="pre">django.contrib.gis.db.models</span></code></a>
had <code class="docutils literal notranslate"><span class="pre">SpatialRefSys</span></code> and <code class="docutils literal notranslate"><span class="pre">GeometryColumns</span></code> models for querying
the OGC spatial metadata tables <code class="docutils literal notranslate"><span class="pre">spatial_ref_sys</span></code> and <code class="docutils literal notranslate"><span class="pre">geometry_columns</span></code>,
respectively.</p>
<p>While these aliases are still provided, they are only for the
<em>default</em> database connection and exist only if the default connection
is using a supported spatial database backend.</p>
<div class="admonition note">
<p class="first admonition-title">注解</p>
<p>Because the table structure of the OGC spatial metadata tables
differs across spatial databases, the <code class="docutils literal notranslate"><span class="pre">SpatialRefSys</span></code> and
<code class="docutils literal notranslate"><span class="pre">GeometryColumns</span></code> models can no longer be associated with
the <code class="docutils literal notranslate"><span class="pre">gis</span></code> application name.  Thus, no models will be returned
when using the <code class="docutils literal notranslate"><span class="pre">get_models</span></code> method in the following example:</p>
<div class="last highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">&gt;&gt;&gt; </span><span class="kn">from</span> <span class="nn">django.db.models</span> <span class="kn">import</span> <span class="n">get_app</span><span class="p">,</span> <span class="n">get_models</span>
<span class="gp">&gt;&gt;&gt; </span><span class="n">get_models</span><span class="p">(</span><span class="n">get_app</span><span class="p">(</span><span class="s1">&#39;gis&#39;</span><span class="p">))</span>
<span class="go">[]</span>
</pre></div>
</div>
</div>
<p>To get the correct <code class="docutils literal notranslate"><span class="pre">SpatialRefSys</span></code> and <code class="docutils literal notranslate"><span class="pre">GeometryColumns</span></code>
for your spatial database use the methods provided by the spatial backend:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="gp">&gt;&gt;&gt; </span><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">connections</span>
<span class="gp">&gt;&gt;&gt; </span><span class="n">SpatialRefSys</span> <span class="o">=</span> <span class="n">connections</span><span class="p">[</span><span class="s1">&#39;my_spatialite&#39;</span><span class="p">]</span><span class="o">.</span><span class="n">ops</span><span class="o">.</span><span class="n">spatial_ref_sys</span><span class="p">()</span>
<span class="gp">&gt;&gt;&gt; </span><span class="n">GeometryColumns</span> <span class="o">=</span> <span class="n">connections</span><span class="p">[</span><span class="s1">&#39;my_postgis&#39;</span><span class="p">]</span><span class="o">.</span><span class="n">ops</span><span class="o">.</span><span class="n">geometry_columns</span><span class="p">()</span>
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">注解</p>
<p>When using the models returned from the <code class="docutils literal notranslate"><span class="pre">spatial_ref_sys()</span></code> and
<code class="docutils literal notranslate"><span class="pre">geometry_columns()</span></code> method, you'll still need to use the
correct database alias when querying on the non-default connection.
In other words, to ensure that the models in the example above
use the correct database:</p>
<div class="last highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">sr_qs</span> <span class="o">=</span> <span class="n">SpatialRefSys</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">using</span><span class="p">(</span><span class="s1">&#39;my_spatialite&#39;</span><span class="p">)</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
<span class="n">gc_qs</span> <span class="o">=</span> <span class="n">GeometryColumns</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">using</span><span class="p">(</span><span class="s1">&#39;my_postgis&#39;</span><span class="p">)</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="s-language-code-no">
<span id="language-code-no"></span><h3>Language code <code class="docutils literal notranslate"><span class="pre">no</span></code><a class="headerlink" href="#language-code-no" title="永久链接至标题">¶</a></h3>
<p>The currently used language code for Norwegian Bokmål <code class="docutils literal notranslate"><span class="pre">no</span></code> is being
replaced by the more common language code <code class="docutils literal notranslate"><span class="pre">nb</span></code>.</p>
</div>
<div class="section" id="s-function-based-template-loaders">
<span id="function-based-template-loaders"></span><h3>Function-based template loaders<a class="headerlink" href="#function-based-template-loaders" title="永久链接至标题">¶</a></h3>
<p>Django 1.2 changes the template loading mechanism to use a class-based
approach. Old style function-based template loaders will still work, but should
be updated to use the new class-based template loaders.</p>
</div>
</div>
</div>


          </div>
        </div>
      </div>
      
        
          <div class="yui-b" id="sidebar">
            
      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
        <div class="sphinxsidebarwrapper">
  <h3><a href="../contents.html">Table of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">Django 1.2 版本发行说明</a><ul>
<li><a class="reference internal" href="#overview">概况</a></li>
<li><a class="reference internal" href="#python-compatibility">Python 兼容性</a></li>
<li><a class="reference internal" href="#what-s-new-in-django-1-2">Django 1.2 新特性</a><ul>
<li><a class="reference internal" href="#support-for-multiple-databases">Support for multiple databases</a></li>
<li><a class="reference internal" href="#model-validation">Model validation</a></li>
<li><a class="reference internal" href="#improved-csrf-protection">Improved CSRF protection</a></li>
<li><a class="reference internal" href="#messages-framework">Messages framework</a></li>
<li><a class="reference internal" href="#object-level-permissions">对象级权限</a></li>
<li><a class="reference internal" href="#permissions-for-anonymous-users">Permissions for anonymous users</a></li>
<li><a class="reference internal" href="#relaxed-requirements-for-usernames">Relaxed requirements for usernames</a></li>
<li><a class="reference internal" href="#email-backends">邮件后端</a></li>
<li><a class="reference internal" href="#smart-if-tag">&quot;Smart&quot; <code class="docutils literal notranslate"><span class="pre">if</span></code> tag</a></li>
<li><a class="reference internal" href="#template-caching">Template caching</a></li>
<li><a class="reference internal" href="#class-based-template-loaders">Class-based template loaders</a></li>
<li><a class="reference internal" href="#natural-keys-in-fixtures">Natural keys in fixtures</a></li>
<li><a class="reference internal" href="#fast-failure-for-tests">Fast failure for tests</a></li>
<li><a class="reference internal" href="#bigintegerfield"><code class="docutils literal notranslate"><span class="pre">BigIntegerField</span></code></a></li>
<li><a class="reference internal" href="#improved-localization">Improved localization</a></li>
<li><a class="reference internal" href="#readonly-fields-in-modeladmin"><code class="docutils literal notranslate"><span class="pre">readonly_fields</span></code> in <code class="docutils literal notranslate"><span class="pre">ModelAdmin</span></code></a></li>
<li><a class="reference internal" href="#customizable-syntax-highlighting">Customizable syntax highlighting</a></li>
<li><a class="reference internal" href="#syndication-feeds-as-views">Syndication feeds as views</a></li>
<li><a class="reference internal" href="#geodjango">GeoDjango</a></li>
<li><a class="reference internal" href="#javascript-assisted-handling-of-inline-related-objects-in-the-admin">JavaScript-assisted handling of inline related objects in the admin</a></li>
<li><a class="reference internal" href="#new-now-template-tag-format-specifier-characters-c-and-u">New <code class="docutils literal notranslate"><span class="pre">now</span></code> template tag format specifier characters: <code class="docutils literal notranslate"><span class="pre">c</span></code> and <code class="docutils literal notranslate"><span class="pre">u</span></code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-2">Backwards-incompatible changes in 1.2</a><ul>
<li><a class="reference internal" href="#csrf-protection">CSRF Protection</a></li>
<li><a class="reference internal" href="#get-db-prep-methods-on-field"><code class="docutils literal notranslate"><span class="pre">get_db_prep_*()</span></code> methods on <code class="docutils literal notranslate"><span class="pre">Field</span></code></a></li>
<li><a class="reference internal" href="#stateful-template-tags">Stateful template tags</a></li>
<li><a class="reference internal" href="#user-passes-test-login-required-and-permission-required"><code class="docutils literal notranslate"><span class="pre">user_passes_test</span></code>, <code class="docutils literal notranslate"><span class="pre">login_required</span></code> and <code class="docutils literal notranslate"><span class="pre">permission_required</span></code></a></li>
<li><a class="reference internal" href="#if-tag-changes"><code class="docutils literal notranslate"><span class="pre">if</span></code> tag changes</a></li>
<li><a class="reference internal" href="#lazyobject"><code class="docutils literal notranslate"><span class="pre">LazyObject</span></code></a></li>
<li><a class="reference internal" href="#dict-on-model-instances"><code class="docutils literal notranslate"><span class="pre">__dict__</span></code> on model instances</a></li>
<li><a class="reference internal" href="#test-runner-exit-status-code">Test runner exit status code</a></li>
<li><a class="reference internal" href="#cookie-encoding">Cookie encoding</a></li>
<li><a class="reference internal" href="#modelform-is-valid-and-modelform-errors"><code class="docutils literal notranslate"><span class="pre">ModelForm.is_valid()</span></code> and <code class="docutils literal notranslate"><span class="pre">ModelForm.errors</span></code></a></li>
<li><a class="reference internal" href="#booleanfield-on-mysql"><code class="docutils literal notranslate"><span class="pre">BooleanField</span></code> on MySQL</a></li>
<li><a class="reference internal" href="#changes-to-the-interpretation-of-max-num-in-formsets">Changes to the interpretation of <code class="docutils literal notranslate"><span class="pre">max_num</span></code> in FormSets</a></li>
<li><a class="reference internal" href="#email-re"><code class="docutils literal notranslate"><span class="pre">email_re</span></code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-2">在 1.2 中被废弃的功能</a><ul>
<li><a class="reference internal" href="#specifying-databases">Specifying databases</a></li>
<li><a class="reference internal" href="#postgresql-database-backend"><code class="docutils literal notranslate"><span class="pre">postgresql</span></code> database backend</a></li>
<li><a class="reference internal" href="#csrf-response-rewriting-middleware">CSRF response-rewriting middleware</a></li>
<li><a class="reference internal" href="#smtpconnection"><code class="docutils literal notranslate"><span class="pre">SMTPConnection</span></code></a></li>
<li><a class="reference internal" href="#user-messages-api">User Messages API</a></li>
<li><a class="reference internal" href="#date-format-helper-functions">Date format helper functions</a></li>
<li><a class="reference internal" href="#function-based-test-runners">Function-based test runners</a></li>
<li><a class="reference internal" href="#feed-in-django-contrib-syndication-feeds"><code class="docutils literal notranslate"><span class="pre">Feed</span></code> in <code class="docutils literal notranslate"><span class="pre">django.contrib.syndication.feeds</span></code></a></li>
<li><a class="reference internal" href="#technical-message-ids">Technical message IDs</a></li>
<li><a class="reference internal" href="#id6">GeoDjango</a><ul>
<li><a class="reference internal" href="#spatialbackend"><code class="docutils literal notranslate"><span class="pre">SpatialBackend</span></code></a></li>
<li><a class="reference internal" href="#spatialrefsys-and-geometrycolumns-models"><code class="docutils literal notranslate"><span class="pre">SpatialRefSys</span></code> and <code class="docutils literal notranslate"><span class="pre">GeometryColumns</span></code> models</a></li>
</ul>
</li>
<li><a class="reference internal" href="#language-code-no">Language code <code class="docutils literal notranslate"><span class="pre">no</span></code></a></li>
<li><a class="reference internal" href="#function-based-template-loaders">Function-based template loaders</a></li>
</ul>
</li>
</ul>
</li>
</ul>

  <h4>上一个主题</h4>
  <p class="topless"><a href="1.2.1.html"
                        title="上一章">Django 1.2.1 版本发行说明</a></p>
  <h4>下一个主题</h4>
  <p class="topless"><a href="1.1.4.html"
                        title="下一章">Django 1.1.4 版本发行说明</a></p>
  <div role="note" aria-label="source link">
    <h3>本页</h3>
    <ul class="this-page-menu">
      <li><a href="../_sources/releases/1.2.txt"
            rel="nofollow">显示源代码</a></li>
    </ul>
   </div>
<div id="searchbox" style="display: none" role="search">
  <h3>快速搜索</h3>
    <div class="searchformwrapper">
    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" />
      <input type="submit" value="转向" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    </div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
              <h3>Last update:</h3>
              <p class="topless">12月 07, 2021</p>
          </div>
        
      
    </div>

    <div id="ft">
      <div class="nav">
    &laquo; <a href="1.2.1.html" title="Django 1.2.1 版本发行说明">previous</a>
     |
    <a href="index.html" title="发行说明" accesskey="U">up</a>
   |
    <a href="1.1.4.html" title="Django 1.1.4 版本发行说明">next</a> &raquo;</div>
    </div>
  </div>

      <div class="clearer"></div>
    </div>
  </body>
</html>